XHTTP transport: Add BBR and brutal-force congestion control for H3#5711
XHTTP transport: Add BBR and brutal-force congestion control for H3#5711
Conversation
|
这事在加hy传输的时候就该弄了 |
|
客户端 dialer 可以先不动，服务端可以先默认设个 bbr 先用着，反正目前也没有 cdn 可以 h3 回源 conn window 那些没必要过度追求 hy，保持默认值就好，congestion 可以在以后动客户端 dialer 的时候再加， |
|
目前用的人不多，两边都默认 bbr 就行， |
|
@Fangliding @LjhAUMEM 所以我觉得给客户端加 bbr 会更有用一些， |
hy 的传输层要求设置个 auth，
两边都默认也行， |
|
|
|
@RPRX xhttp h3也准备能吃bbr了？ |
|
我感觉下行默认BBR就行了 别的不用改 就几行代码 |
You like to have no options to tune and the PR has hardcoded parameters to tune Xray-core/transport/internet/hysteria/dialer.go Lines 196 to 207 in efdf21e
I see no CUBIC CC here, quic-go default is Reno and the added CC is BBR |
暴露无意义的参数只会使配置选项越来越臃肿 你这么喜欢tune你知道bbr里也有一堆硬编码的经验主义参数吗？ |
|
不过对于 QUIC 来说长远来看本来就应该可以自己配置 congestion 参数， 这个 PR 的话先把两端都改为默认 bbr 吧，其它的以后再说 |
|
Should I remove the custom QUIC receive window sizes (2/16/5/32 MB) and revert to quic-go defaults to avoid an externally observable fingerprint? 请问是否需要移除自定义的 QUIC 接收窗口大小（2/16/5/32 MB），恢复为 quic-go 默认值，以避免外部可观测的指纹特征？ |
In the current PR, BBR is already set as the default for both sides. I can move the congestion setting to tlsSettings if needed. 在当前 PR 中，两端已默认使用 BBR。如果需要，我可以将 congestion 配置移到 tlsSettings 中。 |
|
|
|
只是对于 conn window 那些我有点犹豫，默认值应该就行， |
|
Should I make the window sizes configurable in the config rather than hardcoded? 是否需要将 window sizes 做成可配置的，而不是硬编码在代码中？ |
Simply remove these hard-coded conn windows. If you want congestion configuration, add the force-brutal option as well (this may require an additional up/rate/bandwidth field); otherwise, removing the congestion configuration only retains the default bbr. |
Katze-942
changed the title
|
Removed custom QUIC receive window sizes, using quic-go defaults now. I can add 已移除自定义 QUIC 接收窗口大小，改用 quic-go 默认值。 我可以加上 |
|
@RPRX 我想的是除了协商的 brutal 剩下的都可以接过来，但 force 可能要一个新的字段，和 hy 一样 up 还是 |
Katze-942
changed the title
|
Ok, I've added the force-brutal algorithm with the "up" field for now. 好的，我暂时添加了 force-brutal 算法和 "up" 字段。 |
|
要不把所有这些东西都在 tlsSettings 里开一个 |
Haha, it's not exactly 哈哈，这不完全是 brutal。这是 force-brutal，我会在另一个 PR 中添加 brutal 的支持。 |
I'd really like to move this to 我确实想把这些移到 "xhttpSettings": {
"quic": {
"congestion": "force-brutal",
"up": "100 mbps"
}
} |
也可以，
no need to add brutal, xhttp3 is an unauth transport, but force-brutal can be added
Then move the settings to TLS, or keep only the default bbr part (including temporarily removing force-brutal, congestion configuration) and this PR can be merged. |
|
Moved settings to 将设置移至 |
|
looks good to me @RPRX |
刚刚才看到，最近没关注 issue， |
|
@LjhAUMEM Hysteria 传输层除了 version、auth、udphop 以外的参数都能移到新地方对吧 |
|
反正整个 TransportSettings 都是可读的 无聊的话放到wssettings都行 或者专门整个 TransportSettings.QUICParam （为啥放到tls里 因为QUIC用TLS传递window之类的流控参数？不过 brutal 参数不是） |
congestion 的话要带 up down，剩下的就是 quic 类 (9-16)
|
|
主要是放 xhttpSettings 里的话和 hysteriaSettings 里都是重复的内容那看起来很不优雅，然后我想了下放 tlsSettings 里也有同样的问题毕竟 REALITY 以后可能也支持 QUIC， |
|
我之前提的时候刻意写的 |
|
这个我也想过不过没对齐也有点不优雅，但防止搞混还是不对齐吧， |
|
em 我按着里面变量名命名打的 外面 config 肯定长这样 |
|
|
|
这样一来只是方便分享、蹭一下现有的 fm 参数，不过看着会有点怪，像是底层的 finalmask 影响到上层的 quic 了，不过以后 finalmask 挑些 sockopt 加进来再加上它本来就区分了 tcp/udp、v4/v6 的话 sockopt 倒是不违和 |
|
哦还有一个问题 extra 只能写xhttpSettings |
|
以后肯定会重复的，尤其是 REALITY 加了 QUIC 后，连 RAW 都能 QUIC 了，总不能再 copy 给 RAW 一份
|
|
还是先放 finalmask 里面吧，可以蹭到分享链接， |
|
quicparam 不也是分享链接么 |
|
|
|
|
|
Okay, so should I move the QUIC settings to 好的，那我把 QUIC 设置移到 |
|
@Katze-942 是的，在 finalmask 内开个 |
6 participants
I noticed that VLESS TLS with XHTTP transport and ALPN H3 is significantly slower (~2x) compared to regular HTTP/2, and decided to investigate.
Turns out quic-go uses Reno congestion control by default, while TCP gets BBR from the Linux kernel - likely a contributing factor.
On top of that,(removed: keeping quic-go default window sizes) Hard to say which of these matters most, but together they should make a noticeable difference.quic.ListenEarlywas called withnilconfig, so all QUIC parameters were left at quic-go defaults. The default receive windows (512 KB) can also become a bottleneck on high-bandwidth or high-latency links.Both BBR and Brutal implementations reuse the existing
transport/internet/hysteria/congestionpackage (BBR is a port of Google's BBR v1 from Chromium, Brutal is from Hysteria2) to avoid code duplication and build on what's already in the codebase.Also added a
"congestion"setting tofinalmask.quicParams:"bbr"(default) — BBR congestion control"reno"— quic-go default"force-brutal"— Brutal congestion control (requires"up"field)"force-brutal"reuses the existing brutal-force sender from the Hysteria transport (transport/internet/hysteria/congestion/brutal). It sends at a fixed rate regardless of packet loss. Requires the"up"field specifying the target upload bandwidth (same format as Hysteria2, e.g."100 mbps").{ "finalmask": { "quicParams": { "congestion": "force-brutal", "up": "100 mbps" } } }